are we sure we really want to do this? whats going to happen is that mypy issues will just happen on the CI, which is much later in the process.

I don't have a strong point of view but the current usage of mypy is very limited in scope and can in a lot of cases yield a different result than CI anyway. I do think a full mypy run pre-push would be a good compromise instead of a partial run every commit just not sure how feasible that is

This issue is still a thing and for now I solve this with --no-verify at commit, which is not desirable either, since it will skip the other tests as well. Can we maybe add the "needs discussion" tag to have some other opinions as well? @jreback @WillAyd

Just for my understanding, we can't solve the error messages which are occuring now? That would be the most desirable solution right?

we can't solve the error messages which are occuring now?

cc @simonjayhawkins could this be resolved by ensuring that we have the same version of mypy run locally as on the CI?

we can't solve the error messages which are occuring now?

cc @simonjayhawkins could this be resolved by ensuring that we have the same version of mypy run locally as on the CI?

AFAIK mypy runs fine locally with mypy 0.730 (although with other packages adding types e.g. pytest, probably need to make sure local environment matches environment on ci). for ci the dev enviroment is used. i.e. environment.yaml

as far as the pre commit is concerned, I'm on Windows and didn't seem to work out of the box and not spent any time looking any further.

@simonjayhawkins I saw that there were some changes concerning mypy, is PR still relevant?

@simonjayhawkins I saw that there were some changes concerning mypy, is PR still relevant?

I'm not really aware of the issues here, as I don't use pre commit, so I'm not the right person to ask/comment.

Let's just remove it. We can try again once it's more mature.